Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat(orchestrator): membrane-friendly timerUtils #9546

Closed
wants to merge 3 commits into from
Closed

feat(orchestrator): membrane-friendly timerUtils #9546

wants to merge 3 commits into from

Conversation

0xpatrickdev
Copy link
Member

refs: #9449

Description

Towards the goal of membrane compatibility. TimerUtils are not an endowment for orchestrate, nor currently consumed in an async flow, but is consumed by exos/local-orchestration-account.js. It's also planned to be consumed by exo/scosmos-orchestration-account.js

@cloudflare-workers-and-pages Cloudflare Workers and Pages
Copy link

cloudflare-workers-and-pages bot commented Jun 21, 2024 •
edited
Loading

Deploying agoric-sdk with  Cloudflare Pages  Cloudflare Pages

Latest commit: 4c68b4e
Status: ✅  Deploy successful!
Preview URL: https://4ee8317e.agoric-sdk.pages.dev
Branch Preview URL: https://pc-resumable-timer-utils.agoric-sdk.pages.dev

View logs

@0xpatrickdev 0xpatrickdev requested a review from turadg June 21, 2024 01:02
turadg
turadg previously requested changes Jun 21, 2024
View reviewed changes
Copy link
Member

@turadg turadg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a bug in the brand cache.

Also I think I misspoke in calling chainHub resumable in my recent PR. It's returning vows (and thus satisfies 9449) but I think resumable is a higher bar, with durable facets for the watcher callback object. I didn't encounter problems until I used the real vowTools for when and watch instead of the module imports.

packages/orchestration/src/exos/time.js Outdated Show resolved Hide resolved
packages/orchestration/src/exos/time.js Outdated Show resolved Hide resolved
packages/orchestration/src/exos/time.js Outdated Show resolved Hide resolved
@turadg turadg dismissed their stale review June 21, 2024 04:02

bug was fixed

@0xpatrickdev 0xpatrickdev marked this pull request as ready for review June 21, 2024 05:21
@0xpatrickdev 0xpatrickdev requested a review from turadg June 21, 2024 05:21
@0xpatrickdev 0xpatrickdev changed the title feat(orchestrate): resumable timer utils feat(orchestrator): membrane-friendly timerUtils Jun 21, 2024
turadg
turadg previously approved these changes Jun 21, 2024
View reviewed changes
@0xpatrickdev 0xpatrickdev added automerge:rebase Automatically rebase updates, then merge and removed automerge:rebase Automatically rebase updates, then merge labels Jun 21, 2024
@0xpatrickdev 0xpatrickdev requested a review from dckc June 25, 2024 16:44
@0xpatrickdev 0xpatrickdev dismissed turadg’s stale review June 25, 2024 16:46

Refactored to use asVow and durable watcher handlers, so this review is too stale

dckc
dckc reviewed Jun 25, 2024
View reviewed changes
Copy link
Member

@dckc dckc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is an exo for timerUtils really worthwhile? How about making getTimeoutTimestampNS a stateless helper function?

Have it return take an optional timerBrand and return { timestamp, timerBrand } so that the caller can cache the timerBrand if they like. The returned timerBrand would be undefined unless (a) the caller provided it or (b) this function needed to look it up.

@0xpatrickdev
Copy link
Member Author

is an exo for timerUtils really worthwhile? How about making getTimeoutTimestampNS a stateless helper function?

Have it return take an optional timerBrand and return { timestamp, timerBrand } so that the caller can cache the timerBrand if they like. The returned timerBrand would be undefined unless (a) the caller provided it or (b) this function needed to look it up.

My understanding of #9449 is that we'll run into an issue since getTimeoutTimestampNS makes a remote call with E. #9541 is likely the better approach for this scenario - since this is indeed stateless helper function - but that's not ready yet. This code might have a short lifespan but seems necessary towards unblocking us on #9281.

@dckc
Copy link
Member

dckc commented Jun 25, 2024

My understanding of #9449 is that we'll run into an issue since getTimeoutTimestampNS makes a remote call with E.

I'd like to see a test to show that there is such an issue.

I don't think either the calling vat nor the timer service can be upgraded during a call to getCurrentTimestamp(). Surely that's not among the issues we need to address urgently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dckc dckc dckc left review comments

@turadg turadg turadg left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@0xpatrickdev @dckc @turadg